Understanding F5 BIG-IP LTM Traffic Flow (Full Proxy Explained)

When I started learning F5 BIG-IP LTM, the most confusing part for me was how traffic actually flows through the device.

So in this blog, I’ll explain F5 LTM traffic flow using Full Proxy architecture, based on my own notes and understanding.

This post is written from a support engineer’s point of view, focusing on what really happens during a client request.

Network Overview (Simple Architecture)

Let’s consider a basic setup:

• Client Network: 172.16.16.0/24

• F5 External VLAN: 192.168.1.0/24

• F5 Internal VLAN: 10.1.3.0/24

• Servers:

  • S1: 10.1.3.31

  • S2: 10.1.3.32

  • S3: 10.1.3.33

• Virtual Server (VIP): 192.168.1.100

What Is Full Proxy in F5 LTM?

F5 BIG-IP works as a Full Proxy, which means:

• It terminates the client connection

• It creates a separate new connection to the backend server

• Client and server never talk directly to each other

This design gives F5 full control over:

• Load balancing

• SSL offloading

• Security inspection

• Traffic manipulation (iRules, profiles, etc.)

Step-by-Step Traffic Flow

1️⃣ Client Sends Request to VIP

The client sends a request to the Virtual Server:

Client IP: 172.16.16.7
Destination: 192.168.1.100:80

At this point:

• The client thinks it is talking directly to the server

• But it is actually talking to F5

2️⃣ F5 Accepts the Client Connection

F5 accepts the connection on the External VLAN.

• Client-side TCP connection is established

• Entry is created in the connection/session table

• This is called the client-side connection

Example:

172.16.16.7:8443 → 192.168.1.100:80

3️⃣ F5 Terminates Client Connection

Since F5 is a Full Proxy:

• It terminates the client TCP session

• Client-side and server-side connections are handled separately

This is a key concept for troubleshooting.

4️⃣ F5 Creates a New Connection to Backend Server

F5 now opens a new server-side connection using its internal Self IP:

10.1.3.10 → 10.1.3.31:80

Important points:

• Server sees F5 as the client

• Original client IP is not visible unless SNAT is disabled or XFF headers are used

5️⃣ Server Responds to F5

The backend server responds to F5’s internal Self IP:

10.1.3.31 → 10.1.3.10

F5 checks the connection table and maps the response back to the correct client session.

6️⃣ F5 Sends Response Back to Client

F5 sends the response to the client using the original client-side connection.

• Server-side connection may be closed

• Client receives the response as expected

• Client never knows about the internal servers

7️⃣ Session Ends

When the session ends:

• F5 removes the entry from the connection table

• Cleanup happens after timeout or FIN/RST

Connection / Session Table (Very Important)

F5 maintains a connection table in memory, which stores:

• Client-side connection details

• Server-side connection details

• Mapping between both sides

This is why commands like:

tmsh show sys connection

are extremely useful during troubleshooting.

Why Full Proxy Matters in Troubleshooting

Understanding this flow helps you troubleshoot issues like:

• Client connection resets

• Server-side timeouts

• SSL handshake failures

• Asymmetric routing issues

• SNAT-related problems

Many LTM issues become simple once you identify:

“Is the issue on the client side or server side?”

Final Thoughts

This was my first step in deeply understanding F5 LTM traffic flow.
Instead of memorizing commands, focusing on how traffic moves makes troubleshooting much easier.

If you’re also learning F5 and want to grow as a Technical Support Engineer, I hope this post helped you 

Tags(Ignore):#F5

#F5BIGIP

#F5LTM

#F5TAC

#F5Troubleshooting

#TechnicalSupportEngineer

#NetworkEngineering

                                               Learning in public. One concept at a time.